Thanks @geoffreylitt, this is a good start! I pushed a few commits to change some details. In particular, I want to avoid the frontend calling directly into the backend, since that will cause them to become much more closely coupled than they should be.

I moved the the findCursorIndex function to the top-level Automerge module, which is where the integration of frontend and backend takes place. I renamed it to getCursorIndex and swapped its argument order for consistency with the rest of the API. I also made the API exported by the backend explicit.

We will need to make the equivalent change in the Rust implementation to maintain compatibility between the two implementations. This should not be hard.

I will call out that this approach to cursors is incompatible with running frontend and backend on separate threads, since it relies on synchronously calling into the backend. I think that's probably an okay trade-off to make since most Automerge users probably aren't using multiple threads, and having this direct call into the backend is a lot simpler than updating the frontend-backend protocol. But weakening our support for multiple threads is something we should discuss, and make an explicit decision about.

This is great work, I'm glad someone is taking on the cursor challenge 🙂

I'm also concerned about the explicit coupling to the backend. If we rule out the use of different threads for the frontend/backend protocol (and we would be ruling it out in Rust, the Backend and Frontend components have not been designed to be threadsafe and would require a significant rewrite to enable it) then we lose a lot of advantages the design gives us. I'm currently working on performance for the Rust codebase and aiming to make any change that happens on the UI thread fit within a 16ms budget in order to make 60FPS UI possible, removing multithreading makes this extremely difficult.

Is it possible to achieve this same interface by adding an index to the frontend for the element ID <-> list index rather than asking the backend for that information?

@ept thanks, all those updates make sense.

re: frontend/backend split -- as an alternative to @alexjg 's suggestion of maintaining more state in the frontend, what if getCursorIndex was a function exposed by the backend, and the user could choose to either: 1) synchronously call the backend as in the current PR, 2) wire up their own messaging to make an async call.

I guess one problem might be that until now the protocol has entirely consisted of change requests going one way and patches going the other, and this would be adding a new kind of message that would need to be handled?

This PR is based on the Automerge 0.x release series. As we are now focussing our attention on the performance branch and the 1.x series, we can use the implementations of cursors in #307 or #313 instead, so I will close this PR. Thanks for getting us started on cursors, though!